How we built our multi-agent research system

How we built our multi-agent research system

promptもある!!

Claude のResearch機能は、このマルチエージェントの仕組みでできている

システムの仕組み

メインエージェント

リサーチプロセスの計画

パラレルエージェント

ツールの使用

情報の同時検索

開発からの学び

システムアーキテクチャ

ツール設計

プロンプトエンジニアリング

マルチエージェントシステムの課題

エージェントの協調

評価

信頼性

マルチエージェントシステムの利点

オープンエンド（終わりのない、答えが一意に定まらない）な問題への対応

研究プロセスの特性

予測不可能性

動的な性質

AIエージェントの適合性

柔軟性

自律性

検索の本質は圧縮

膨大なコーパスから洞察を抽出する

圧縮と並列処理

サブエージェントの役割

並列探索

コンテキストの分離

重要情報の凝縮

関心の分離

各サブエージェントの独立性

ツール、プロンプトー、探索の軌跡を区別

経路依存性の低減

知能が閾値に達すれば、マルチエージェントシステムにパフォーマンススケーリングは不可欠

パフォーマンスのスケーリング

知能の閾値到達後の重要性

集合知との類似性

個別エージェントの限界克服

内部評価

強み

幅優先クエリ

複数方向の同時追求

性能の要因

主要因：十分なトークン使用

パフォーマンス分散の理由

トークン使用量（分散の80%

ツールコール

モデル選択

欠点と限界

トークン消費が激しい

経済的な実行可能性

不適合な領域

コンテキストを共有する必要があったり

エージェント依存関係が多いもの

例：コーディングタスク

並列化が困難

最適なユースケース

高度な並列化を伴う勝ちがある

単一コンテキストウインドウを超える情報処理

多数の複雑なインターフェースを含むタスク

アーキテクチャ

https://gyazo.com/f3260f0d7bc1d3fa11ebda801d86da5c

https://gyazo.com/ca1bc0ead2f0444d1f822a3a40aff3f7

code:mmd

flowchart TD

%% Nodes

L(LeadResearcher)

style M stroke-dasharray: 5 5

subgraph Parallel_Search

direction LR

S1(Subagent #1)

S2(Subagent #2)

end

D{More research?}

C(CitationAgent)

%% Edges

U --> L

L -->|store plan| M

L -->|spawn| S1

L -->|spawn| S2

S1 -->|query| T1 --> R1 --> L

S2 -->|query| T2 --> R2 --> L

L -->|synthesize| D

D -- Yes --> L

D -- No --> C --> A --> U

ちょっと変だけど

研究エージェントのための迅速なエンジニアリングと評価

マルチエージェントシステムには、

調整の複雑さの急速な増大など、

シングルエージェントシステムとの重要な違いがある。

初期のエージェントのミス

単純なクエリに対して50のサブエージェントを生成したり、

存在しないソースを延々とウェブで探し回ったり、

過剰な更新で互いの気を散らしたりする

各エージェントはプロンプトによって誘導されるため、プロンプトエンジニアリングはこれらの行動を改善するための主要な手段でした。

エージェントをプロンプト化するために学んだいくつかの原則

1. エージェントのように考える。

プロンプトを反復するためには、その効果を理解する必要があります。

私たちのシステムのプロンプトとツールをそのまま使ったシミュレーションを行い、

エージェントがステップ・バイ・ステップで作業する様子を観察しました。

コンソールを使って

失敗モードの特定

エージェントがすでに十分な結果を得ているのに続行したり、

過度に冗長な検索クエリを使用したり、

誤ったツールを選択したり

効果的なプロンプトは、エージェントの正確なメンタルモデルを開発することに依存します。

2. オーケストレーターに委任の仕方を教える。

我々のシステムでは、リードエージェントがクエリをサブタスクに分解し、サブエージェントに説明する。

サブエージェントへの詳細なタスク記述

目的

出力フォーマット

使用するツールやソースに関するガイダンス、

明確なタスクの境界線

曖昧な指示による問題の回避

タスクの誤解

作業の重複

私たちは、「半導体不足を調査せよ」というような簡単で短い指示をリード・エージェントに与えることから始めたが、このような指示が曖昧であるために、サブエージェントがタスクを誤解したり、他のエージェントと全く同じ検索を行ったりすることがしばしばあることがわかった。

例えば、あるサブエージェントが2021年の自動車用チップの危機を調査する一方で、他の2人のサブエージェントが現在の2025年のサプライチェーンを調査する作業を重複して行い、効果的な分業が行われなかった。

3. クエリの複雑さに応じて労力のスケーリングを行う。

エージェントは、異なるタスクに対する適切な労力を判断するのに苦労する

プロンプトにスケーリングルールを組み込んだ。

単純な事実調査: 1人のエージェントが3-10回のツール呼び出しで済み、

直接比較: 2-4人のサブエージェントがそれぞれ10-15回の呼び出しで済み、

複雑な調査: 10人以上のサブエージェントが明確な役割分担のもと使用することができる。

このような明確なガイドラインは、リード・エージェントがリソースを効率的に配分し、

初期のバージョンでよく見られた単純なクエリへの過剰投資を防ぐのに役立ちます。

4. ツールの設計と選択

エージェントとツールのインターフェースは、人間とコンピュータのインターフェースと同じくらい重要である。

適切なツールを使うことは効率的であり、多くの場合、それは厳密に必要である。

例えば、Slackにしか存在しないコンテキストをウェブで検索するエージェントは、最初から破滅的である。

モデルに外部ツールへのアクセスを提供するMCPサーバーでは、エージェントが質の大きく異なる説明を持つ未知のツールに遭遇するため、この問題はさらに悪化する。

我々はエージェントに明示的なヒューリスティックを与えた。

利用可能な全てのツールを最初に調べる、

ツールの使い方をユーザーの意図に合わせる、

広く外部を探索するためにウェブを検索する、

汎用的なものよりも特化したツールを好む、などである。

悪いツールの説明は、エージェントを完全に間違った道へと導く可能性があるため、各ツールには明確な目的と明確な説明が必要である。

私たちは、クロード4のモデルが優れたプロンプトエンジニアになれることを発見しました。

診断と改善提案

プロンプトと故障モードが与えられると、エージェントはなぜ故障しているのかを診断し、

改善策を提案することができます。

欠陥のあるMCPツールが与えられると、そのツールの使用を試み、失敗を避けるためにツールの説明を書き換えます。

ツールテストエージェント

ツールを何十回もテストすることで、このエージェントは重要なニュアンスやバグを発見した。

ツールの人間工学を改善するこのプロセスにより、新しい記述を使用した将来のエージェントは、ほとんどのミスを回避できるようになったため、

タスク完了時間が40％短縮された。

6. まずは広く、それから絞り込む。

検索戦略は、専門家によるリサーチを反映したものであるべきだ。

短く広範なクエリから開始する

段階的に絞り込む

エージェントはしばしば、結果をほとんど返さないような、長くて具体的なクエリをデフォルトにしてしまいます。

私たちは、エージェントに短く幅広いクエリから始め、利用可能なものを評価し、徐々に焦点を絞るよう促すことで、この傾向を打ち消しました。

7. 思考プロセスを導く

拡張思考モード

クロードが目に見える思考プロセスで追加のトークンを出力するように導く

制御可能なスクラッチパッドとして機能することができる

リードエージェント

思考を利用してアプローチを計画し、どのツールがタスクに適合するかを評価し、クエリの複雑さとサブエージェント数を決定し、各サブエージェントの役割を定義する。

我々のテストでは、拡張された思考が指示への追従性、推論、効率を向上させることが示された。

サブエージェント

計画を立て、ツールの結果後にインターリーブ思考を使用して、品質を評価し、ギャップを特定し、次のクエリを改良する。

これにより、サブエージェントはどのようなタスクにも効果的に適応できるようになる。

8. 並列ツール呼び出しがスピードとパフォーマンスを変える

複雑な研究タスクは、当然ながら多くの情報源を探索することになる。

初期のエージェントは逐次検索を実行していたが、これは非常に遅いものであった。

1. リードエージェントからサブエージェントへの並列呼び出し

2. サブエージェントは3つ以上のツールを並行して使用する。

これらの変更により、複雑なクエリに対する調査時間を最大90%削減

リサーチが他のシステムよりも多くの情報をカバーしながら、

数時間ではなく数分でより多くの作業をこなせるようになりました。

私たちのプロンプト戦略

厳格なルールではなく、優れたヒューリスティックを植え付ける

例えば、

難しい質問をより小さなタスクに分解する、

情報源の質を注意深く評価する、

新しい情報に基づいて検索アプローチを調整する、

深さ（1つのトピックを詳細に調査する）と広さ（多くのトピックを並行して調査する）のどちらに重点を置くべきかを認識する、といった戦略である。

また、エージェントが制御不能に陥るのを防ぐために、明確なガードレールを設定することで、意図しない副作用を積極的に緩和した。

最後に、観測可能性とテストケースを備えた高速な反復ループに焦点を当てました。

効果的なエージェントの評価

評価の課題

マルチエージェントシステムの特有の難しさ

従来の評価手法の不適合

固定的パスの想定

エージェントの多様な有効経路

柔軟な評価手法の必要性

結果とプロセスの合理性評価

評価手法

小規模サンプルでの即時評価

開発初期の有効性

少数のテストケースで十分な効果測定

大規模評価を待たない即時開始の推奨

スケーラブルな評価

自由形式テキストの評価に適合

ルーブリック評価基準

事実の正確性 主張と出店は一致しているか

引用の正確性 引用された出典は主張と一致しているか

完全性 要求されたすべての側面がカバーされているか

ソースの品質 質の低い二次資料よりも一次資料を使用しているか

ツールの効率性 適切なツールを妥当な回数使用しているか

一貫性のある評価方法

単一LLM、単一プロンプト

0.0～1.0のスコアと合格・不合格の評点を出力する1つのプロンプトを持つ単一のLLMコールが最も一貫性があり、人間の判断と一致していることがわかりました。

この方法は、評価テストケースに明確な答えがあり、その答えが正しいかどうかをLLMの判定者がチェックする場合に特に効果的でした（研究開発予算トップ3の製薬会社が正確にリストアップされているかなど）。

LLMをジャッジとして使用することで、何百ものアウトプットをスケーラブルに評価することができました。

人間による評価

自動化が見逃すエッジケースの発見

通常とは異なるクエリに対する幻覚的な回答

システム障害、

微妙なソース選択の偏りなどが含まれる。

手動テストは不可欠

私たちの場合、初期のエージェントは、学術的なPDFや個人のブログのような権威はあるが、それほど高く評価されていないソースよりも、SEOに最適化されたコンテンツファームを一貫して選択していたことに、人間のテスターが気づきました。ソース品質のヒューリスティックをプロンプトに追加することで、この問題を解決することができました。自動化された評価の世界でも、手動テストは不可欠です。

マルチエージェントシステム特有の考慮事項

創発的行動

リードエージェントへの小さな変更がサブエージェントの行動を予測不可能に変化させる

成功の鍵

相互作用パターンの理解

最適なプロンプト

単なる厳密な指示ではなく

協調のためのフレームワーク

分業

問題解決アプローチ

労力バジェット（予算）を定義する

これを実現する要素

慎重なプロンプティングとツール設計

堅実なヒューリスティクス

可観測性

緊密なフィードバックループ

本番の信頼性とエンジニアリングの課題

従来のソフトウェア

バグが機能を破壊し、パフォーマンスを低下させ、機能停止を引き起こすかもしれない。

エージェントシステム

複雑なエージェントのコードを書くのは非常に難しい。

些細な変更が大きな動作の変更に連鎖する

長時間実行されるプロセスで状態を維持しなければならない

状態保持とエラーの複合

課題：軽微なシステム障害の壊滅的影響

エラー処理

耐久性を高く行う必要がある

最初から再開はだめ

コストがかかるし、フラストレーションが溜まる

対策

エラー箇所からの再開機能

モデルの知能による適応

ツールが故障したときにエージェントに知らせ、適応させる

deterministic 決定論的　セーフガードの併用

デバッグの新アプローチ

課題：非決定性によるデバッグの困難化

エージェントは動的決定をするので非決定的

対策

本番環境の完全なトレーシング

高レベルな可観測性

標準的な可観測性だけじゃない

エージェントの意思決定パターンやインタラクション構造も監視する

デプロイの慎重な調整

課題：実行中エージェントの破損リスク

対策：レインボーデプロイメント

同期実行のボトルネック

課題：情報フローのボトルネック

対策案：非同期実行

非同期の課題

結果調整

状態一貫性

エラー伝播

同期実行はボトルネックを生む。現在、我々のリード・エージェントはサブエージェントを同期的に実行し、各サブエージェントのセットが完了するのを待ってから処理を進めている。これは調整を単純化しますが、エージェント間の情報の流れにボトルネックを生じます。例えば、リードエージェントはサブエージェントを操縦できず、サブエージェントは協調できず、一つのサブエージェントが検索を終えるのを待っている間にシステム全体がブロックされる可能性がある。非同期実行は、エージェントが同時に作業し、必要なときに新しいサブエージェントを作成するという、さらなる並列性を可能にする。しかし、この非同期性によって、結果の調整、状態の一貫性、サブエージェント間のエラー伝播に課題が生じる。モデルがより長く、より複雑な研究タスクを扱うことができるようになれば、性能の向上が複雑さを正当化することを期待しています。

結論

...

appendix